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1. Introduction 


This document describes the framework for Interface to Network 
Security Functions (I2NSF) and defines a reference model (including 
major functional components) for I2NSF. This includes an analysis of 
the threats implied by the deployment of Network Security Functions 
(NSFs) that are externally provided. It also describes how I2NSF 
facilitates implementing security functions in a technology- and 
vendor-independent manner in Software-Defined Networking (SDN) and 
Network Function Virtualization (NFV) environments, while avoiding 
potential constraints that could limit the capabilities of NSFs. 


I2NSF use cases [RFC8192] call for standard interfaces for users of 
an I2NSF system (e.g., applications, overlay or cloud network 
management system, or enterprise network administrator or management 
system) to inform the I2NSF system which I2NSF functions should be 


applied to which traffic (or traffic patterns). The I2NSF system 
realizes this as a set of security rules for monitoring and 
controlling the behavior of different traffic. It also provides 


standard interfaces for users to monitor flow-based security 
functions hosted and managed by different administrative domains. 


[RFC8192] also describes the motivation and the problem space for an 
Interface to Network Security Functions system. 


2. Conventions Used in This Document 
This memo does not propose a protocol standard, and the use of words 
such as "should" follow their ordinary English meaning and not that 
for normative languages defined in [RFC2119] [RFC8174]. 
2.1. Acronyms 
The following acronyms are used in this document: 
DOTS: Distributed Denial-of-Service Open Threat Signaling 
IDS: Intrusion Detection System 
IoT: Internet of Things 


IPS: Intrusion Protection System 
NSF: Network Security Function 
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I2NSF Framework 


Definitions 


The following terms, which are used in this document, 
the I2NSF terminology document [I2NSF-TERMS]: 


Lopez, 


Capability 
Controller 
Firewall 


I2NSF 
I2NSF 
I2NSF 
I2NSF 
I2NSF 
I2NSF 


Consumer 

NSF-Facing Interface 
Policy Rule 

Producer 

Registration Interface 
Registry 


Interface 

Interface Group 

Intrusion Detection System 
Intrusion Protection System 
Network Security Function 


Role 
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3- 


I2NSF Reference Model 


Figure 1 shows a reference model (including major functional 
components and interfaces) for an I2NSF system. This figure is drawn 
from the point of view of the Network Operator Management System; 
hence, this view does not assume any particular management 
architecture for either the NSFs or how the NSFs are managed (on the 
developer’s side). In particular, the Network Operator Management 
System does not participate in NSF data-plane activities. 


| I2NSF User (e.g., Overlay Network Mgmt, Enterprise | 
| Network Mgmt, another network domain’s mgmt, etc.) | 
4+-------------------- 4---------------------------------- + 


I2NSF Consumer-Facing Interface 


| I2NSF 
portarne PaaS Seas + Registration +------------- + 
| Network Operator Mgmt | Interface | Developer's | 
| System | < --------- > | Mgmt System 
+---------------- +-----— + +------------- + 
| 
| I2NSF NSF-Facing Interface 
| 
+--------------- +----+------------ +--------------- + 
| | | | 
+-—-+---+ +---+---+ +---+---+ +---+---+ 
| NSF-1 | | NSF-m | | NSF-1 | | NSF-m | 
+------- + +------- + +------- + +------- + 
Developer Mgmt System A Developer Mgmt System B 


Figure 1: I2NSF Reference Model 


When defining I2NSF Interfaces, this framework adheres to the 
following principles: 


o It is agnostic of network topology and NSF location in the network 


o It is agnostic of provider of the NSF (i.e., independent of the 
way that the provider makes an NSF available, as well as how the 
provider allows the NSF to be managed) 


o It is agnostic of any vendor-specific operational, administrative, 
and management implementation; hosting environment; and form 
factor (physical or virtual) 
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o It is agnostic to NSF control-plane implementation (e.g., 
signaling capabilities) 


o It is agnostic to NSF data-plane implementation (e.g., 
encapsulation capabilities) 


In general, all I2NSF Interfaces should require at least mutual 
authentication and authorization for their use. Other security and 


privacy considerations are specified in Section 11. 


3.1. I2NSF Consumer-Facing Interface 


The I2NSF Consumer-Facing Interface is used to enable different users 
of a given I2NSF system to define, manage, and monitor security 
policies for specific flows within an administrative domain. The 
location and implementation of I2NSF policies are irrelevant to the 
consumer of I2NSF policies. 


Some examples of I2NSF Consumers include: 


o A video-conference network manager that needs to dynamically 
inform the underlay network to allow, rate-limit, or deny flows 
(some of which are encrypted) based on specific fields in the 
packets for a certain time span. 


o Enterprise network administrators and management systems that need 
to request their provider network to enforce specific I2NSF 
policies for particular flows. 


o An IoT management system sending requests to the underlay network 
to block flows that match a set of specific conditions. 


3.2. I2NSF NSF-Facing Interface 


The I2NSF NSF-Facing Interface (NSF-Facing Interface for short) is 
used to specify and monitor flow-based security policies enforced by 
one or more NSFs. Note that the I2NSF Management System does not 
need to use all features of a given NSF, nor does it need to use all 
available NSFs. Hence, this abstraction enables NSF features to be 
treated as building blocks by an NSF system; thus, developers are 
free to use the security functions defined by NSFs independent of 
vendor and technology. 
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Flow-based NSFs [RFC8192] inspect packets in the order that they are 
received. Note that all Interface Groups require the NSF to be 
registered using the Registration Interface. The interface to flow- 
based NSFs can be categorized as follows: 


1. NSF Operational and Administrative Interface: an Interface Group 
used by the I2NSF Management System to program the operational 
state of the NSF; this also includes administrative control 
functions. I2NSF Policy Rules represent one way to change this 
Interface Group in a consistent manner. Since applications and 
I2NSF Components need to dynamically control the behavior of 
traffic that they send and receive, much of the I2NSF effort is 
focused on this Interface Group. 


2. Monitoring Interface: an Interface Group used by the I2NSF 
Management System to obtain monitoring information from one or 
more selected NSFs. Each interface in this Interface Group could 
be a query- or a report-based interface. The difference is that 
a query-based interface is used by the I2NSF Management System to 
obtain information, whereas a report-based interface is used by 
the NSF to provide information. The functionality of this 
Interface Group may also be defined by other protocols, such as 
SYSLOG and DOTS. The I2NSF Management System may take one or 
more actions based on the receipt of information; this should be 
specified by an I2NSF Policy Rule. This Interface Group does NOT 
change the operational state of the NSF. 


This document uses the flow-based paradigm to develop the NSF-Facing 
Interface. A common trait of flow-based NSFs is in the processing of 
packets based on the content (e.g., header/payload) and/or context 
(e.g., session state and authentication state) of the received 
packets. This feature is one of the requirements for defining the 
behavior of I2NSF. 


3.3. I2NSF Registration Interface 


NSFs provided by different vendors may have different capabilities. 
In order to automate the process of utilizing multiple types of 
security functions provided by different vendors, it is necessary to 
have a dedicated interface for vendors to define the capabilities of 
(i.e., register) their NSFs. This interface is called the I2NSF 
Registration Interface. 


An NSF’s capabilities can be either pre-configured or retrieved 
dynamically through the I2NSF Registration Interface. If a new 
function that is exposed to the consumer is added to an NSF, then the 
capabilities of that new function should be registered in the I2NSF 
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Registry via the I2NSF Registration Interface, so that interested 
management and control entities may be made aware of them. 


4. Threats Associated with Externally Provided NSFs 


While associated with a much higher flexibility, and in many cases a 
necessary approach given the deployment conditions, the usage of 
externally provided NSFs implies several additional concerns in 
security. The most relevant threats associated with a security 
platform of this nature are: 


o An unknown/unauthorized user can try to impersonate another user 
that can legitimately access external NSF services. This attack 
may lead to accessing the I2NSF Policy Rules and applications of 
the attacked user and/or generating network traffic outside the 
security functions with a falsified identity. 


o An authorized user may misuse assigned privileges to alter the 
network traffic processing of other users in the NSF underlay or 
platform. 


o A user may try to install malformed elements (e.g., I2NSF Policy 
Rules or configuration files) to directly take control of an NSF 
or the whole provider platform. For example, a user may exploit a 
vulnerability on one of the functions or may try to intercept or 
modify the traffic of other users in the same provider platform. 


o A malicious provider can modify the software (e.g., the operating 
system or the specific NSF implementation) to alter the behavior 
of one or more NSFs. This event has a high impact on all users 
accessing NSFs, since the provider has the highest level of 
privileges controlling the operation of the software. 


o A user that has physical access to the provider platform can 
modify the behavior of the hardware/software components or the 
components themselves. For example, the user can access a serial 
console (most devices offer this interface for maintenance 
reasons) to access the NSF software with the same level of 
privilege of the provider. 


The use of authentication, authorization, accounting, and audit 
mechanisms is recommended for all users and applications to access 
the I2NSF environment. This can be further enhanced by requiring 
attestation to be used to detect changes to the I2NSF environment by 
authorized parties. The characteristics of these procedures will 
define the level of assurance of the I2NSF environment. 
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5. Avoiding NSF Ossification 


A basic tenet in the introduction of I2NSF standards is that the 
standards should not make it easier for attackers to compromise the 
network. Therefore, in constructing standards for I2NSF Interfaces 
as well as I2NSF Policy Rules, it is equally important to allow 
support for specific functions, as this enables the introduction of 
NSFs that evolve to meet new threats. Proposed standards for I2NSF 
Interfaces to communicate with NSFs, as well as I2NSF Policy Rules to 
control NSF functionality, should not: 


o Narrowly define NSF categories, or their roles, when implemented 
within a network. Security is a constantly evolving discipline. 
The I2NSF framework relies on an object-oriented information 
model, which provides an extensible definition of NSF information 
elements and categories; it is recommended that implementations 
follow this model. 


o Attempt to impose functional requirements or constraints, either 
directly or indirectly, upon NSF developers. Implementations 
should be free to realize and apply NSFs in a way that best suits 
the needs of the applications and environment using them. 


o Be a limited lowest common denominator approach, where interfaces 
can only support a limited set of standardized functions, without 
allowing for developer-specific functions. NSFs, interfaces, and 
the data communicated should be extensible, so that they can 
evolve to protect against new threats. 


o Be seen as endorsing a best common practice for the implementation 
of NSFs; rather, this document describes the conceptual structure 
and reference model of I2NSF. The purpose of this reference model 
is to define a common set of concepts in order to facilitate the 
flexible implementation of an I2NSF system. 


To prevent constraints on NSF developers’ creativity and innovation, 
this document recommends flow-based NSF interfaces to be designed 
from the paradigm of processing packets in the network. Flow-based 
NSFs are ultimately packet-processing engines that inspect packets 
traversing networks, either directly or in the context of sessions in 
which the packet is associated. The goal is to create a workable 
interface to NSFs that aids in their integration within legacy, SDN, 
and/or NFV environments, while avoiding potential constraints that 
could limit their functional capabilities. 


Lopez, et al. Informational [Page 9] 


RFC 8329 I2NSF Framework February 2018 


6. The Network Connecting I2NSF Components 
6.1. Network Connecting I2NSF Users and the I2NSF Controller 


As a general principle, in the I2NSF environment, users directly 
interact with the I2NSF Controller. Given the role of the I2NSF 
Controller, a mutual authentication of users and the I2NSF Controller 
is required. I2NSF does not mandate a specific authentication 
scheme; it is up to the users to choose available authentication 
schemes based on their needs. 


Upon successful authentication, a trusted connection between the user 
and the I2NSF Controller (or an endpoint designated by it) will be 
established. This means that a direct, physical point-to-point 
connection, with physical access restricted according to access 
control, must be used. All traffic to and from the NSF environment 
will flow through this connection. The connection is intended not 
only to be secure but trusted in the sense that it should be bound to 
the mutual authentication between the user and the I2NSF Controller, 
as described in [I2NSF-ATTESTATION]. The only possible exception is 
when the required level of assurance is lower (see Section 4.1 of 
[I2NSF-ATTESTATION]), in which case the user must be made aware of 
this circumstance. 


6.2. Network Connecting the I2NSF Controller and NSFs 


Most likely, the NSFs are not directly attached to the I2NSF 
Controller; for example, NSFs can be distributed across the network. 
The network that connects the I2NSF Controller with the NSFs can be 
the same network that carries the data traffic, or it can be a 


dedicated network for management purposes only. In either case, 
packet loss could happen due to failure, congestion, or other 
reasons. 


Therefore, the transport mechanism used to carry management data and 
information must be secure. It does not have to be a reliable 
transport; rather, a transport-independent reliable messaging 
mechanism is required, where communication can be performed reliably 
(e.g., by establishing end-to-end communication sessions and by 
introducing explicit acknowledgement of messages into the 
communication flow). Latency requirements for control message 
delivery must also be evaluated. Note that monitoring does not 
require reliable transport. 
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The network connection between the I2NSF Controller and NSFs can rely 
on either: 


o Open environments, where one or more NSFs can be hosted in one or 
more external administrative domains that are reached via secure 
external network connections. This requires more restrictive 
security control to be placed over the I2NSF Interface. The 
information over the I2NSF Interfaces shall be exchanged by using 
the trusted connection described in Section 6.1, or 


o Closed environments, where there is only one administrative 


domain. Such environments provide a more **isolated** environment 
but still communicate over the same set of I2NSF Interfaces 
present in open environments (see above). Hence, the security 


control and access requirements for closed environments are the 
same as those for open environments. 


The network connection between the I2NSF Controller and NSFs will use 
the trusted connection mechanisms described in Section 6.1. 

Following these mechanisms, the connections need to rely on the use 
of properly verified peer identities (e.g., through an 
Authentication, Authorization, and Accounting (AAA) framework). The 
implementations of identity management functions, as well as the AAA 
framework, are out of scope for I2NSF. 


6.3. Interface to vNSFs 


There are some unique characteristics in interfacing to virtual NSFs 
(vNSFs) : 


o There could be multiple instantiations of one single NSF that has 
been distributed across a network. When different instantiations 
are visible to the I2NSF Controller, different policies may be 
applied to different instantiations of an individual NSF (e.g., to 
reflect the different roles that each vNSF is designated for). 
Therefore, it is recommended that Roles, in addition to the use of 
robust identities, be used to distinguish between different 
instantiations of the same vNSF. Note that this also applies to 
physical NSFs. 


o When multiple instantiations of one single NSF appear as one 
single entity to the I2NSF Controller, the I2NSF Controller may 
need to get assistance from other entities in the I2NSF Management 
System and/or delegate the provisioning of the multiple 
instantiations of the (single) NSF to other entities in the I2NSF 
Management System. This is shown in Figure 2 below. 
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o Policies enforced by one vNSF instance may need to be retrieved 
and moved to another vNSF of the same type when user flows are 
moved from one vNSF to another. 


o Multiple vNSFs may share the same physical platform. 


o There may be scenarios where multiple vNSFs collectively perform 
the security policies needed. 


hee ea ee oe ee + 
| I2NSF Controller 
HSS Ses Soe See + 
| 
4+----------- + 4+------------ + 
v v 
Poia an o ee ee a a h 
| NSF-A +-------------- + | | NSF-B +-------------- + | 
| NSF Manager | | | NSF Manager | 
| +-------------- + | | +-------------- + | 
Jena onia e a i o a E Phen e es a ee ee eee ee ep 
| +--------- + $--------- +| iaa --------- + +--------—- +| 
| || NSF-A#1 | ... | NSF-A#n || | | || NSF-B#1 | ... | NSF-B#m || | 
| |#--------- bo += +| | | [4--------- + +=- +| | 
| | NSF-A cluster iis Okt NSF-B cluster | | 
[ee cEs we ey ue ees cee ell, E ene, E ea ean tal 
Ph m Te cc e a e E T e A E A 
Figure 2: Cluster of NSF Instantiations Management 
6.4. Consistency 


There are three basic models of consistency: 
o centralized, which uses a single manager to impose behavior 


o decentralized, in which managers make decisions without being 
aware of each other (i.e., managers do not exchange information) 


o distributed, in which managers make explicit use of information 
exchange to arrive at a decision 


This document does NOT make a recommendation on which of the above 
three models to use. I2NSF Policy Rules, coupled with an appropriate 
management strategy, is applicable to the design and integration of 
any of the above three consistency models. 
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7. %I2NSF Flow Security Policy Structure 


Even though security functions come in a variety of form factors and 
have different features, provisioning to flow-based NSFs can be 
standardized by using policy rules. 


In this version of I2NSF, policy rules are limited to imperative 
paradigms. I2NSF is using an Event-Condition-Action (ECA) policy, 
where: 


o An Event clause is used to trigger the evaluation of the Condition 
clause of the I2NSF Policy Rule. 


o A Condition clause is used to determine whether or not the set of 
Actions in the I2NSF Policy Rule can be executed or not. 


o An Action clause defines the type of operations that may be 
performed on this packet or flow. 


Each of the above three clauses are defined to be Boolean clauses. 
This means that each is a logical statement that evaluates to either 
TRUE or FALSE. 

The above concepts are described in detail in [I2NSF-CAPABILITIES]. 


7.1. Customer-Facing Flow Security Policy Structure 


This layer is for the user’s network management system to express and 
monitor the needed flow security policies for their specific flows. 


Some customers may not have the requisite security skills to express 
security requirements or policies that are precise enough to 


implement in an NSF. These customers may instead express 
expectations (e.g., goals or intent) of the functionality desired by 
their security policies. Customers may also express guidelines, such 


as which types of destinations are (or are not) allowed for certain 
users. As a result, there could be different levels of content and 
abstractions used in Service Layer policies. Here are some examples 
of more abstract security policies that can be developed based on the 
I2NSF-defined Customer-Facing Interface: 

o Enable Internet access for authenticated users 


o Any operation on a HighValueAsset must use the corporate network 


o The use of FTP from any user except the CxOGroup must be audited 
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o Streaming media applications are prohibited on the corporate 
network during business hours 


o Scan email for malware detection; protect traffic to corporate 
network with integrity and confidentiality 


o Remove tracking data from Facebook [website = *.facebook.com] 


One flow policy over the Customer-Facing Interface may need multiple 
NSFs at various locations to achieve the desired enforcement. Some 
flow security policies from users may not be granted because of 
resource constraints. [I2NSF-DEMO] describes an implementation of 
translating a set of 1) user policies to flow policies and 2) flow 
policies to individual NSFs. 


T2NSF will first focus on user policies that can be modeled as 
closely as possible to the flow security policies used by individual 
NSFs. An I2NSF user flow policy should be similar in structure to 
the structure of an I2NSF Policy Rule, but with more of a user- 
oriented expression for the packet content, the context, and other 
parts of an ECA policy rule. This enables the user to construct an 
I2NSF Policy Rule without having to know the exact syntax of the 
desired content (e.g., actual tags or addresses) to match in the 
packets. For example, when used in the context of policy rules over 
the Client-Facing Interface: 


o An Event can be "the client has passed the AAA process" 


o A Condition can be matching the user identifier or from specific 
ingress or egress points 


o An Action can be establishing an IPsec tunnel 

7.2. NSF-Facing Flow Security Policy Structure 
The NSF-Facing Interface is to pass explicit rules to individual NSFs 
to treat packets, as well as methods to monitor the execution status 
of those functions. 
Here are some examples of Events over the NSF-Facing Interface: 
o time == 08:00 


o notification that a NSF state changes from standby to active 


o user logon or logoff 
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Here are some examples of Conditions over the NSF-Facing Interface: 


o Packet content values that look for one or more packet headers, 
data from the packet payload, bits in the packet, or data that are 
derived from the packet. 


o Context values that are based on measured and/or inferred 
knowledge, which can be used to define the state and environment 
in which a managed entity exists or has existed. In addition to 
state data, this includes data from sessions, direction of the 
traffic, time, and geo-location information. State refers to the 
behavior of a managed entity at a particular point in time. 
Hence, it may refer to situations in which multiple pieces of 
information that are not available at the same time must be 
analyzed. For example, tracking established TCP connections 
(connections that have gone through the initial three-way 
handshake). 


Actions to individual flow-based NSFs include: 


o Actions performed on ingress packets, such as pass, drop, rate 
limiting, and mirroring. 


o Actions performed on egress packets, such as invoke signaling, 
tunnel encapsulation, packet forwarding, and/or transformation. 


o Applying a specific functional profile or signature -- e.g., an 
IPS Profile, a signature file, an anti-virus file, or a URL 
filtering file. Many flow-based NSFs utilize profile and/or 
signature files to achieve more effective threat detection and 
prevention. It is not uncommon for an NSF to apply different 
profiles and/or signatures for different flows. Some profiles/ 
signatures do not require any knowledge of past or future 
activities, while others are stateful and may need to maintain 
state for a specific length of time. 


The functional profile or signature file is one of the key properties 
that determine the effectiveness of the NSF and is mostly NSF 
specific today. The rulesets and software interfaces of I2NSF aim to 
specify the format to pass profile and signature files while 
supporting specific functionalities of each. 


Policy consistency among multiple security function instances is very 
critical because security policies are no longer maintained by one 
central security device; instead, they are enforced by multiple 
security functions instantiated at various locations. 
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7.3. Differences from ACL Data Models 


Policy rules are very different from Access Control Lists (ACLs). An 
ACL is NOT a policy. Rather, policies are used to manage the 
construction and life cycle of an ACL. 


[ACL-YANG] has defined rules for ACLs supported by most routers/ 
switches that forward packets based on their L2, L3, or sometimes L4 
headers. The actions for ACLs include Pass, Drop, or Redirect. 


The functional profiles (or signatures) for NSFs are not present in 
[ACL-YANG] because the functional profiles are unique to specific 
NSFs. For example, most IPS/IDS implementations have their 
proprietary functions/profiles. One of the goals of I2NSF is to 
define a common envelope format for exchanging or sharing profiles 
among different organizations to achieve more effective protection 
against threats. 


The "packet content matching" of the I2NSF policies should not only 
include the matching criteria specified by [ACL-YANG] but also the 
L4-L7 fields depending on the NSFs selected. 


Some flow-based NSFs need matching criteria that include the context 
associated with the packets. This may also include metadata. 


The I2NSF "actions" should extend the actions specified by [ACL-YANG] 
to include applying statistics functions, threat profiles, or 
signature files that clients provide. 


8. Capability Negotiation 


It is very possible that the underlay network (or provider network) 
does not have the capability or resources to enforce the flow 
security policies requested by the overlay network (or enterprise 
network). Therefore, it is required that the I2NSF system support 
dynamic discovery capabilities, as well as a query mechanism, so that 
the I2NSF system can expose appropriate security services using I2NSF 
capabilities. This may also be used to support negotiation between a 
user and the I2NSF system. Such dynamic negotiation facilitates the 
delivery of the required security service(s). The outcome of the 
negotiation would feed the I2NSF Management System, which would then 
dynamically allocate appropriate NSFs (along with any resources 
needed by the allocated NSFs) and configure the set of security 
services that meet the requirements of the user. 


When an NSF cannot perform the desired provisioning (e.g., due to 
resource constraints), it must inform the I2NSF Management System. 
The protocol needed for this security function/capability negotiation 
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9. 


9. 


may be somewhat correlated to the dynamic service parameter 
negotiation procedure described in [RFC7297]. The Connectivity 
Provisioning Profile (CPP) template, even though currently covering 
only connectivity requirements, includes security clauses such as 
isolation requirements and non-via nodes. Hence, it could be 
extended as a basis for the negotiation procedure. Likewise, the 
companion Connectivity Provisioning Negotiation Protocol (CPNP) could 
be a candidate for the negotiation procedure. 


"Security-as-—a-Service" would be a typical example of the kind of 
(CPP-based) negotiation procedures that could take place between a 
corporate customer and a service provider. However, more security- 
specific parameters have to be considered. 


[I2NSF-CAPABILITIES] describes the concepts of capabilities in 
detail. 


Registration Considerations 
1. Flow-Based NSF Capability Characterization 


There are many types of flow-based NSFs. Firewall, IPS, and IDS are 
the commonly deployed flow-based NSFs. However, the differences 
among them are definitely blurring, due to more powerful technology, 
integration of platforms, and new threats. Basic types of flow-based 
NSFs include: 


o Firewall -- A device or a function that analyzes packet headers 
and enforces policy based on protocol type, source address, 
destination address, source port, destination port, and/or other 
attributes of the packet header. Packets that do not match policy 
are rejected. Note that additional functions, such as logging and 
notification of a system administrator, could optionally be 
enforced as well. 


o IDS (Intrusion Detection System) -- A device or function that 
analyzes packets, both header and payload, looking for known 
events. When a known event is detected, a log message is 
generated detailing the event. Note that additional functions, 
such as notification of a system administrator, could optionally 
be enforced as well. 


o IPS (Intrusion Prevention System) -- A device or function that 
analyzes packets, both header and payload, looking for known 
events. When a known event is detected, the packet is rejected. 
Note that additional functions, such as logging and notification 
of a system administrator, could optionally be enforced as well. 
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Flow-based NSFs differ in the depth of packet header or payload they 
can inspect, the various session/context states they can maintain, 
and the specific profiles and the actions they can apply. An example 
of a session is as follows: allowing outbound connection requests and 
only allowing return traffic from the external network. 


9.2. Registration Categories 


Developers can register their NSFs using packet content matching 
categories. The Inter-Domain Routing (IDR) Flow Specification 
[RFC5575] has specified 12 different packet header matching types. 


IP Flow Information Export (IPFIX) data [IPFIX-D] defines IP flow 
information and mechanisms to transmit such information. This 
includes flow attributes as well as information about the metering 
and exporting processes. Such information may be stored in an IPFIX 
registry [IPFIX-R]. As such, IPFIX information should be considered 
when defining categories of registration information. 


More packet content matching types have been proposed in the IDR WG. 
I2NSF should reuse the packet matching types being specified as much 
as possible. More matching types might be added for flow-based NSFs. 


Figures 3-6 below list the applicable packet content categories that 
can be potentially used as packet matching types by flow-based NSFs: 


Layer 2 header fields: | 
Source | 
Destination | 
s-VID | 

c-VID 

Ethertype 


H 
ie) 
< 
o 
B 
N 
——— 


Layer 3 header fields: 
protocol 
dest port 
src port 
src address 
dest address 
dscp 
length 
flags 
ttl 


IPv4 Header 


He 
+} 
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IPv6 Header 
protocol/nh 
src port 
dest port 
src address 
dest address 
length 
traffic class 
hop limit 
flow label 
dscp 


| 
| 
| 
| 
| 
+ 
| Layer 4 header fields: 
| Port 
| syn 
DCCP ack 
| fin 
| rst 
| ? psh 
| ? urg 
| ? window 
| sockstress 
Note: bitmap could be used to 
| represent all the fields 
UDP | 
| flood abuse 
| fragment abuse 
| Port 
+ 
| 
| 
| 
| 


HTTP layer 
| hash collision 

| http - get flood 
| http - post flood 

http - random/invalid url 

http - slowloris 
| http - slow read | 
| http - r-u-dead-yet (rudy) | 
| http - malformed request | 
| | 


jf E 


http - xss 
https - ssl session exhaustion 
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S EEEN A A SSeS Ssess + 
| IETF PCP | Configurable | 
| | Ports | 
+--------------- +----------------------- === + 
| IETF TRAM | profile | 
+--------------- ea ee oe ae ee + 
Notes 

DCCP: Datagram Congestion Control Protocol 

PCP: Port Control Protocol 


TRAM: TURN Revised and Modernized, where TURN stands for 
Traversal Using Relays around NAT 


Figure 3: Packet Content Matching Capability Index 


Po SaeSSSes Sse SSS SSeS se SSS ee Se SS Se SSS ses SsessH + 
| Context Matching Capability Index 
+--------------- +-------------------------- === === + 
| Session | Session State, 
| | Bidirectional State | 
4+--------------- fe ee ee ee E + 
Time Time span 
Time occurrence 
4+--------------- PSS SSR ae SS SS See + 
| Events | Event URL, variables 
4+--------------- PesSSestossSese SSS saa Sse Se SS esa SSS SsSaa= + 
| Location | Text string, GPS coords, URL 
Pasa S ree aaa SoS $33 S525 5 SS SS SSS Se a ee Sees + 
| Connection | Internet (unsecured), Internet 
| Type | (secured by VPN, etc.), Intranet, ... | 
4+--------------- SE Te cal a ce cles rca crc SS ag a a + 
| Direction | Inbound, Outbound 
+--------------- +------------------------ == === + 
State Authentication State 


Authorization State 
| | Accounting State | 
| | Session State | 


Note: 
These fields are used to provide context information for 
I2NSF Policy Rules to make decisions on how to handle 
traffic. For example, GPS coordinates define the location 
of the traffic that is entering and exiting an I2NSF 
system; this enables the developer to apply different 
rules for ingress and egress traffic handling. 


Figure 4: Context Matching Capability Index 
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poo SSS Sa OSS SSS SS SES eS Se Se ae SS Seas + 
| Action Capability Index 
poe oe ae tio tS ee oe Be ee eee eee aS + 
| Ingress port | SFC header termination, | 
| | VxLAN header termination | 
4+--------------- 4----------- 5-5-5555 = + 
| | Pass | 
| Actions | Deny 
Mirror 
Simple Statistics: Count (X min; Day;..) 
| |  Client-Specified Functions: URL 
Prasat Fossadal + 
| Egress | Encap SFC, VxLAN, or other header 
Spo eee ea hoe SS eS ee eS ee eee + 
Note: 
SFC Service Function Chaining 
Figure 5: Action Capability Index 
t--------- 5-5-5 5-5-5 5 5 a 5 = + 
| Functional Profile Index 
Sp Se eee Sa FOSS SSS SHAS SS SS SS eS + 
| Profile types | name, type, or flexible 
| 
| Signature | Profile/signature URL command for the 
| | I2NSF Controller to enable/disable | 
4+--------------- SS ee ee ee + 


Figure 6: Functional Profile Index 


10. Manageability Considerations 


Management of NSFs include: 


Life-cycle management and resource management of NSFs 


Configuration of devices, such as address configuration, device 
internal attributes configuration, etc. 


Policy rules provisioning 


I2NSF only focuses on the policy rule provisioning part. 


(0) 
fe) 
o Signaling 
(0) 
Currently, 
Lopez, et al. 


Informational [Page 21] 


RFC 8329 I2NSF Framework February 2018 


11. Security Considerations 


The configuration, control, and monitoring of NSFs provide access to 
and information about security functions that are critical for 
delivering network security and for protecting end-to-end traffic. 
Therefore, it is important that the messages that are exchanged 
within this architecture utilize a trustworthy, robust, and fully 
secure communication channel. The mechanisms adopted within the 
solution space must include proper secure communication channels that 
are carefully specified for carrying the controlling and monitoring 
information between the NSFs and their management entity or entities. 
The threats associated with remotely managed NSFs are discussed in 
Section 4, and solutions must address those concerns. 


This framework is intended for enterprise users, with or without 
cloud service offerings. Privacy of users must be provided by using 
existing standard mechanisms, such as encryption; anonymization of 
data should also be done if possible (depending on the transport 
used). Such mechanisms require confidentiality and integrity. 


12. IANA Considerations 


This document has no IANA actions. 
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